packages/dart/lib/parse_server_sdk.dart (1)

12-12: Narrow http import to avoid potential symbol clashes with dio

Given this is the root library for many part files and you already import package:dio/dio.dart, bringing in all of package:http/http.dart risks name clashes (e.g., Response) in any part that uses unqualified types.

Since the only thing needed here is ClientException for buildParseResponseWithException, consider narrowing the import:

-import 'package:http/http.dart';
+import 'package:http/http.dart' show ClientException;

This keeps the namespace clean while still enabling the new exception handling.

Please double‑check that no other symbols from http are used anywhere in the parts of this library before applying this change.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

packages/dart/lib/src/objects/response/parse_exception_response.dart (1)

26-30: ClientException mapping fixes the bug; consider a more specific error code

Handling ClientException explicitly and surfacing exception.message directly addresses the original issue and keeps the original exception attached, which is good.

If you want to distinguish network/client errors from generic ones, you could optionally set a dedicated ParseError code here (for example a “connection failed” constant, if available in this SDK) instead of relying on the default otherCause. That would make it easier for callers to branch on network vs. server errors.

Example (only if you decide to specialize the code):

-  if (exception is ClientException) {
-    return ParseResponse(
-      error: ParseError(message: exception.message, exception: exception),
-    );
-  }
+  if (exception is ClientException) {
+    return ParseResponse(
+      error: ParseError(
+        message: exception.message,
+        exception: exception,
+        // Consider using a dedicated connection/network error code here.
+      ),
+    );
+  }

This is optional and can be deferred.

packages/dart/test/src/objects/response/parse_exception_response_test.dart (1)

1-72: Good coverage of exception-mapping behavior; consider one more small case

These tests nicely pin down the behaviors for:

• DioException with JSON payload (message + string code),
• DioException with non-JSON body (status message/code fallback),
• http ClientException,
• generic Exception,

and they verify that the original exception object is preserved in all cases. This is exactly what the production code is doing.

If you want one more safety net, you could add a variant of the first test where code is an integer ('code': 123) to guard against future regressions in the numeric-path handling, but that’s strictly a nice-to-have.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro